MODBUS, Profibus, Devicenet, CANOpen and Ethernet-based networks are utilized in factory automation and related fields for communicating between data processing systems and peripheral devices. Local area networks (LAN) interconnect factory equipment and other devices such as programmable logic controllers (PLC) e.g., any of the Quantum PLCs by Schneider Automation Inc., fieldbus couplers (FBC), IO modules (such as analog input, digital input, analog output, or digital output modules), motion controllers, vision controllers, invertors, encoders, process controller, numerical controllers, relays, sensors, bar code readers, weighing stations, cubing machines, power monitoring equipment, breakers, industrial power monitors, and computer work stations for monitoring and programming PLCs and other devices related to factory automation. The MODBUS protocol is widely used for factory automation applications. The MODBUS protocol is described in the MODBUS Protocol Reference Guide, publication PIMBUS-000 by Schneider Automation Inc. and is incorporated herein by reference. MODBUS Plus is a LAN protocol for industrial control applications. Applications of the MODBUS Plus protocol are described in the MODBUS Plus Network and Installation Guide, 890 USE 100 00 Version 3.0, Schneider Electric, April 1996, and is incorporated by reference.
The MODBUS protocol is well known and is described, for example, on the World Wide Web, (Web) at http://www.modbus.org, along with all related Web pages. Different networking schemes relating to factory automation are described in U.S. Pat. Nos. 6,151,625; 5,805,442; 5,251,302; and 5,699,350, and are also incorporated herein by reference.
A MODBUS frame comprises three basic parts. The first part is an address field for storing a device identifier (ID). The ID identifies the slave device to which the MODBUS frame is to be sent when the message is being sent from a master device. When the frame originates at a slave device and is to be sent to a master device, the ID identifies the slave device from which the MODBUS frame was sent. Thus, a master addresses a slave by placing the slave address in the address field of the message, and when the slave sends its response, the slave places its own address in the address field to inform the master which slave is responding. Further contained in the MODBUS frame is a function code. The function code informs the receiving device what type of function or operation will be performed by the MODBUS protocol handler at the slave device. For example, a function code, 126, causes a subsystem of devices to start or stop depending upon function code 126's subcode, i.e., 1 or 2. Yet another function code, function code 125, reads the hardware identification to the master device. The last part of the MODBUS frame includes a data field containing data pertinent to the function code in question, i.e., the Encapsulated Interface Transport message for function code 43 in the present invention.
Although MODBUS has become an industry standard, other technologies have been developed for different automation activities. MODBUS, as originally designed, was a serial communication protocol that had a limited number of nodes in a master/slave relationship. The master node is the network node issuing the MODBUS frame, while the slave node is the receiver of the MODBUS frame. In addition, MODBUS serial line frames are limited to 256 bytes in length.
In recent years, the MODBUS protocol has been adapted to operate on several other transport mechanisms. MODBUS Plus was introduced in the late 1980s to provide a higher speed interface with more flexible cabling options.
In the mid-1990s, MODBUS was again adapted to execute on Ethernet-based networks in the form of a protocol called MODBUS/TCP. This protocol provides a message packet within TCP to encapsulate the MODBUS message, allowing for communications throughout the Internet. The network speed was greatly increased, as were the cabling options. And the address space limitations were removed. Further information on the MODBUS/TCP implementation can be found at http://www.modbus.org.
Because of the compatibility between MODBUS, MODBUS Plus, and MODBUS/TCP, there are a number of advantages to encapsulating other protocols within a MODBUS message. Messages can now be transported between networks running these protocols to devices that run other protocols (“tunnelling messages”). Furthermore, messages can be sent between devices that understand MODBUS for further delivery to a processor that can understand the encapsulated message. In both scenarios, there are advantages in the interoperability that MODBUS provides.
One of the greatest advantages would be in the tunnelling of HTTP and its associated encoding mechanisms. HTTP encoded in MODBUS allows simple remote devices that may only support MODBUS or MODBUS/TCP to communicate with a remote browser.
HTTP protocols are well known in the art as a mechanism for communicating across the Internet, especially between computer processes and a web browser. HTTP communications is typically over well known TCP port 80 and is encoded using ASCII commands. For instance, a request for a web page might consist of a message from a web browser to a remote station as follows:
HTTP Communications - Port 80RequestGET http://controller15.company.com/home.htmlHTTP/1.0ResponseHTTP/1.0 200 OK<HTML>Controller Status: RUNNING<\HTML>
There are a number of commands and responses that are allowed in an HTTP message. To further understand HTTP, please look at the “Hypertext Transfer Protocol—HTTP/1.1”, RFC 2616, specification, hereby incorporated by reference.
Within the HTTP message, data is often returned in HTML, XML, SGML, or XHTML or other similar hypertext languages. These languages are also described in detail by the W3C at www.w3c.org in the specifications for each of these protocols.